Container Runtime
개요
컨테이너가 돌아가는 환경.
즉, 이미지를 이용해 프로세스를 격리시키고 리소스를 할당하여 돌릴 수 있는 환경을 말한다.
가장 유명한 것은 도커의 dockerd.
Kubernetes가 등장하면서 구조가 조금 더 체계화되어 CRI와 OCI의 개념이 정립되었고, 이로부터 다양한 환경이 등장하게 됐다.
쿠버네티스 v1.24부터는 이제 도커데몬을 지원하지 않기에 다른 툴을 활용하는 것이 권장된다.
참고로 쿠버네티스에서 동작 가능한 컨테이너 런타임 인터페이스를 CRI라고 부른다.
구조
컨테이너 런타임이라고 하면, 두 가지 층위가 나뉜다.
이에 맞춰 각각의 툴들이 활발하게 개발되고 있다.
CSI 레벨 컨테이너 런타임
OCI 레벨 컨테이너 런타임
- runc
- containerd, dockerd에서 활용하는 가장 대중적인 런타임
- crun
- 레드햇에서 개발한 경량 런타임
- runc와 비교하여 최적화가 잘 돼있다고 함
- runsc
- gVisor라고도 불리는, 샌드박스형 런타임
- 보안이 조금 더 강화돼있다.
- Kata container
- 가상 머신(KVM)을 활용하는 런타임
- 컨테이너처럼 쓰는 가상머신!
- youki
- Rust로 개발된 런타임이라고 한다.
- runc와 비교하여 최적화가 잘 돼있다고 함
쿠버네티스에서 제한사항
네트워크
# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
기본적으로 리눅스는 인터페이스를 통한 ip 통신에 대해 라우팅을 허용하지 않는다.
대체로 이 세팅은 쿠버네티스 설치 시 알아서 이뤄지나, 간혹 직접 해야 하는 경우도 존재하니 방법을 알아두는 것이 좋다.
방법은 설정을 파일로 남기고, sysctl로 동적으로 커널 모듈을 로드하는 것이다.
cgroup driver
cgroups#cgroup 관리 미들웨어 종류에는 두 가지가 있는데, kubelet에서 사용하는 드라이버와 노드의 컨테이너 런타임의 드라이버는 일치해야만 한다.
최근 리눅스에서는 systemd, kubelet에서는 cgroupfs가 기본으로 설정되어 있으므로 이를 보정하는 작업이 필요하다.
cgroup 2버전이 나오며 systemd를 사용하는 것이 자연스레 권장되고 있으며, 애초에 systemd가 init 프로세스에 들어가기에 이쪽을 사용하는 쪽이 좋다.
kubeadm 1.22 버전 이후부터는 아무런 설정이 없을 시 알아서 kubelet도 systemd로 설정된다.
1.28 버전부터는 kubelet의 feature gate에서 설정을 통해 kubelet이 알아서 현재 컴퓨터의 cgroup driver를 동적으로 활용할 수 있도록 하는 것이 가능하다.
처음 설치 시에는 이미 한번 실행된 이후에 적용할 수 있기에 이 방법은 그다지 유효해보이지는 않는다.
두 드라이버 충돌하게 되는 상황이 나와버리면, 가령 cgroupfs를 통해 리소스가 관리되던 파드가 있는 상태에서 설정이 바뀌면 예상치 못한 에러가 발생할 수 있다.
containerd 설정
Containerd에서는 /etc/containerd/config.toml파일을 수정한다.
이 부분을 true로 걸면 된다.
이후에는 systemctl restart containerd.
CRI-O 설정
아직 만져본 적이 없어서 나중에 만져보면 적용하겠다.